home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Jan 91 / MacApp.Tech$ 1⁄25⁄91 / 2747-War in the Language -Jan91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  7.5 KB  |  130 lines  |  [TEXT/GEOL]
  1. Item    2065999                         19-Jan-91        13:06PST
  2.  
  3. From:   SPA0137                         Objectsoft SA, Spain,IDV
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. cc:     BERDAHL                         Amoco Tech, Eric Berdahl,VAR
  8.         PHAROS.TECH                     Pharos Tech, Tech Staff,PRT
  9.         INFO-PASCAL++@CAMBRIDGE.APPLE.COM@INTERNET# 
  10.  
  11. Item forwarded by       SPA.DTS      to SPA0144 
  12.  
  13. ------------------------------------------------------------------------------
  14.  
  15. Sub:    War in the Language Gulf
  16.  
  17. Well, its been some months since flames came shooting out of my in box and I've
  18. finally had my fill of this Pascal 9X compared to C++ nonsense so here goes.
  19.  
  20. I originally started programming in Pascal because it was the first language to
  21. popularize identifiers longer than eight or even two characters, (sorry C still
  22. had only eight back then and it still shows) and because it allowed me to add
  23. my own data types to the language. Also because I liked the way my algorithms
  24. looked when written in Pascal. Now lately I've read some mail offering to
  25. convert my Pascal to C, the more portable language, ha! I've just spent a few
  26. hours with the source of Bison, the Yacc replacement trying to compile it under
  27. MPW and if anyone else calls C portable I think I will retch. Furthermore, if
  28. you've ever tried to write you own parser driver for Yacc by modifying an
  29. existing one then you've seen a host of variables like yylloc, and yytloc.
  30. Well, about the only thing you CAN do is say, "Why, why…?"
  31.  
  32. Now I've read that C++ lets you "express your ideas in a greater number of ways
  33. and with a finer degree of distinction" and that "everyone’s doing it and
  34. you’ll be cool?". I believe the last reason is probably the only one with a
  35. grain of truth to it. I've heard that C++ is the right tool for some jobs and
  36. that Pascal 9x is the result of feature envy on the part of Pascal programmers.
  37. I don't know about anyone else out there, but I've read some of the C++
  38. archives and I don't envy anybody who uses that language. They seem to spend a
  39. lot of time trying to get things to work right.
  40.  
  41. Ken Addison, in a link to me long ago when I was getting zapped for Pascal++
  42. and Multiple Inheritance comments, pointed out that the real issue is analysis
  43. and design and not really the choice of language. I have to agree with him but
  44. I'd like to go a bit farther along with this topic. I think that it is hard for
  45. people to say what makes a good piece of program code, and although words like
  46. elegant, simple and obvious spring to mind, I don't think anyone has figured
  47. out how to make a compiler check for these things. This is precisly the
  48. problem. Sure you can write "object oriented" code in COBOL and it might even
  49. look beautiful to another COBOL programmer. But it is this "analysis and
  50. design" part that made it look good. However, if you are really doing good
  51. analysis and design, doesn't it make sense to implement in a language that is
  52. also elegant and simple? For the sake of maintainability and reusability (even
  53. if reuse by copy and paste) doesn't it make sense to choose a language based
  54. upon its simplicity instead of some criteria like a greater number and finer
  55. degree of features? Or a kinder and gentler preprocessor?
  56.  
  57. In light of some of the links, I'm not even going to bother with the
  58. readability argument for Pascal. If you find C++ more readable that's your
  59. business. No doubt Russians find cyrillic readable. Let's assume that each is
  60. equally readable. I think its not a question of which language is more readable
  61. but of which group of programmers wants to be more readable. Clearly it is an
  62. issue of philosphy.
  63.  
  64. So what bothers me isn't the discussion about languages. It isn't reading a
  65. bunch of links about obscure C++ features. What worries me is complicated
  66. e-mail adresses like info-pascal++@cambridge.apple.com@INTERNET#, and other
  67. uses of #$&|%++ in what should be plain, if not simple, English. As far as I
  68. know there is no group of Pascal programmers out there who regularly have a
  69. contest to write obfuscated code. The same cannot be said for C. (Check out
  70. your old CD-ROMs if you don't believe) I think that Pascal programmers would be
  71. loath to enter a Obfuscated Pascal contest whereas C programmers obviously
  72. delight in such things. This doesn't mean that C++ programmers are writing bad
  73. code or are guilty of poor design. However until they prove otherwise, they are
  74. guilty by association.
  75.  
  76. However the Pascal interfaces to MacApp are getting more and more obfuscated
  77. anyway. Are we going to have a high priesthood of Mac programmers now? If I
  78. wanted to belong to a priesthood I could get a very lucrative job working in
  79. 370 assembler.
  80.  
  81. Who can look at the current MacApp source and tell me with a straight face that
  82. it is elegant and simple? It is based upon some elegant and simple ideas, but
  83. they seem to be getting lost in the code. Some new language features would help
  84. make MacApp better for sure. But it reminds me of the hoopla over structured,
  85. goto-less programming in the '70s. So far, no matter how many nice features are
  86. added to programming languages, someone can figure out how to write gargbage
  87. code with them. In many cases, the wealth of features just means that the
  88. majority of code will be even more incomprehensible because programmers have a
  89. tendency to try and use every feature if they can. I think this is really the
  90. point the people who don't use C++ are trying to make. (And this is a potential
  91. land mine in a new Pascal that might have too many new features.)
  92.  
  93. What will make our class libraries better is not adding new features to the
  94. language, but adding more and better design up-front. It won't matter if they
  95. are written in C++ if the design is done right. But it would be nice to see the
  96. algorithms written in a language that everyone can read easily without trying
  97. to figure out which of 1000 features is being used at each turn. But if this
  98. doesn't happen then so be it. And if in the future we all end up working with
  99. class libraries that make the Obfuscated C contest look like a seminar on good
  100. programming style, it will be because we didn't pay any attention to the
  101. philosphy of readability.
  102.  
  103. Back when I started programming Apple computers, the idea was to make things
  104. simple for the user. (This wis pre-Macintosh, by the way) The argument is that
  105. simplicity and power are not at odds with each other. Are programmers not
  106. users? Lately it seems that Macintosh programmers crave complexity at a dire
  107. cost to ourselves and the users. Meanwhile the whole Apple organization is
  108. running on the momentum of ideas that nobody seems to be able to express
  109. verbally or otherwise anymore. I see more and more AppleLinks with UNIX headers
  110. at the top, forcing me to scroll just to read some English. The Tech Notes keep
  111. growing while the Human Interface guys cry out like voices in the wilderness.
  112. If you just started programming the Macintosh (in other words you never used a
  113. Lisa) then wake up! Stop using preprocessors and scripts and shells and working
  114. on CAD systems that only the shop-floor robots can understand. If you like
  115. bits, and inline code then use your talent to build a nice interactive object
  116. environment that mortals can use to write some really neat stuff! Somewhere
  117. between HyperTalk and MPW Object Pascal lies a really good language.
  118.  
  119.  
  120. Spilling the soup on everyone,
  121.  
  122. Barry Wilson
  123. ObjectSoft
  124.  
  125. P.S. Why not go to the horse's mouth on this subject. I've never seen Object
  126. Oberon's design, but I'm sure it can't be all bad. Wirth has a good track
  127. record on language design. Even if he hasn't published anything maybe he'll be
  128. willing to share with Apple on this.
  129.  
  130.